[FLINK-39711][runtime] Expose maxExceptions on exception message parameters#28202
[FLINK-39711][runtime] Expose maxExceptions on exception message parameters#28202jubins wants to merge 3 commits into
Conversation
…meters The REST endpoint GET /jobs/:jobid/exceptions accepts an optional maxExceptions query parameter, but Java clients of Flink's typed REST API could not set it: the corresponding MessageQueryParameter fields on JobExceptionsMessageParameters and ApplicationExceptionsMessageParameters were declared private. This forced downstream Java clients (e.g. flink-kubernetes-operator) to fetch the full job exception history on every observation tick, wasting network bytes, JobManager-side serialization time, and operator JVM memory for long-running jobs with large exception histories.
… rendering Covers the newly accessible upperLimitExceptionParameter and failureLabelExceptionParameter fields on JobExceptionsMessageParameters, and upperLimitExceptionParameter on ApplicationExceptionsMessageParameters, by asserting end-to-end URL rendering via MessageParameters.resolveUrl. Also verifies that unresolved optional parameters are omitted from the rendered URL.
|
@jubins The CI is failing, changes need a lint fix. |
davidradl
left a comment
davidradl
left a comment
There was a problem hiding this comment.
This change looks reasonable. It now enables a server flow, that could not be called before . Is this server side code path tested somewhere? Or do we need to add an integration style test.
done |
@davidradl thanks for your review! For Application endpoint, while checking I noticed ApplicationExceptionsHandler doesn't read Since that's wider than client-side accessibility, I'll scope this PR to the job endpoint and have filed a follow-up JIRA FLINK-39730 for the application-side wiring + field exposure. Happy to expand here instead if you'd prefer one PR, just let me know. |
4 participants
What is the purpose of the change
Fixes FLINK-39711 - the REST endpoint
GET /jobs/:jobid/exceptionsaccepts an optionalmaxExceptionsquery parameter that bounds the response size, but Java clients of Flink's typed
REST API could not set it: the corresponding
MessageQueryParameterfields onJobExceptionsMessageParametersandApplicationExceptionsMessageParameterswere declared
private. This forced downstream clients (e.g. flink-kubernetes-operator) to fetch the full job exception history on every observation tick,
wasting network bytes, JobManager-side serialization time, and operator JVM memory
for long-running jobs with large exception histories.
Brief change log
upperLimitExceptionParameteronJobExceptionsMessageParametersfromprivate finaltopublic final, matching the convention used by every otherMessageParameterssubclass (e.g.JobMessageParameters,JobMetricsMessageParameters,JobVertexFlameGraphParameters).failureLabelExceptionParameteron the same class,which had the identical accessibility gap.
upperLimitExceptionParameteronApplicationExceptionsMessageParameters.JobExceptionsHandler/ApplicationExceptionsHandlerareunchanged — this only opens up the existing parameter to typed Java clients.
Verifying this change
This change is covered by new unit tests:
JobExceptionsMessageParametersTest— verifies that resolvingupperLimitExceptionParameterandfailureLabelExceptionParameterproduces theexpected query string on the rendered URL, and that optional parameters are
omitted when unresolved.
ApplicationExceptionsMessageParametersTest— same coverage for theapplication endpoint.
Existing
JobExceptionsHandlerTestcontinues to validate that the server-sidehandler reads the parameter from the request.
Does this pull request potentially affect one of the following parts
@Public(Evolving): no — neitherJobExceptionsMessageParametersnorApplicationExceptionsMessageParameterscarries an@Public/@PublicEvolvingannotation. The change only widens field visibility, so it is source- and binary-compatible.Documentation
server-side query parameter to Java REST clients.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Opus 4.7